今天測的技能包來自一個全新的來源——anthropics/knowledge-work-plugins，官方剛開源，給非工程職能用的技能包，法務、財務、HR、業務、PM、資料分析各一包，明確寫著相容 Claude Code，可以直接裝進來用。這系列前 26 天測的都是寫程式相關的技能，今天換一個完全不同的戰場：法務的 review-contract，合約審查。

先設計一份藏了陷阱的合約

準備了一份供應商 SaaS 服務的主服務合約，站在採購方的角度藏了幾個會真的讓人吃虧的條款：賠償責任條款只要求我方賠對方、完全沒有對方賠我方的義務，而責任上限條款又把賠償義務排除在上限之外——兩條分開看都還好，疊在一起看，就是我方的賠償責任沒有上限，對方的責任卻封頂。另外還埋了一個續約通知陷阱：通知期限寫得不算短，但規定只能用掛號信寄送，email 跟系統後台都無效，一疏忽就被多綁一年。

分別跑了兩種條件：直接把合約丟給它看，跟套上 review-contract 技能、告知無公司內部議約手冊（用它自己文件寫的「沒有 playbook 就用通用商業標準審查」這條路徑）。

兩邊都抓到了那個藏得最深的問題

結果兩邊都抓出了賠償條款疊責任上限這個組合拳，也都抓到了掛號信才有效的續約陷阱，連資料授權範圍過寬、終止權單方且無救濟這幾條也都提了。單看「有沒有看出問題」，兩邊幾乎是同一個水準——這點其實不意外，前幾天測 code review 類技能時也看過同樣的結果：一個本來就夠強的模型，看不看得出問題，從來不是它的瓶頸。

差別出現在「看出問題之後，給了什麼」

沒套技能那邊，產出是一份分級風險清單，每條問題配一句建議方向。套了技能那邊，產出是一份可以直接寄給對方的工作底稿：每條問題都附上具體的修改條文草稿、一個保底的退讓方案、要升級給誰簽核才能接受，最後還把所有問題打包成三個談判優先層級，附上一份兩週內怎麼來回談判的時間表，連「這份分析沒有串接公司的合約管理系統、所有數字都是通用起點不是公司內部標準」這種限制，也老實寫在了結尾。這不是「同一個結論換個說法」，是兩種完全不同份量的產出——一份是判斷，一份是可以直接拿去用的半成品。

這跟昨天測的落差不一樣

昨天測的 spec-kit 留下的落差，是規則讀起來很嚴謹、實際運作時卻沒被觸發。今天這個落差完全不同：它實際做的事，真的超出了另一邊會做的事，差別不在判斷力，在於它願不願意把判斷力的產出往前再推一步，推到一份已經可以行動的文件，而不是停在「這裡有問題」。

這對實際用途的意義

如果只是想知道「這份合約有沒有問題」，兩種做法得到的答案差不多，不值得為此多裝一個技能。但如果真正要做的事是跟對方來回談判、需要一份能馬上送出去的條文草案跟一份能跟主管報告的優先順序，這類技能省下來的不是判斷的時間，是把判斷轉成工作產出的那段時間——而這段時間，實務上往往比看出問題本身更長。

跟前面幾天放在一起看

這系列測過不少「結構有沒有改變判斷」的案例，大多數結論是判斷力沒變，變的是表達方式。今天是少數「判斷力沒變，但產出的東西種類整個不一樣」的例子——這個差異比單純換個語氣更實際，也更貼近真的要用這類技能做事的人會在意的地方。

明天找下一個方向繼續測，候選清單還在累積。